home *** CD-ROM | disk | FTP | other *** search
/ Columbia Kermit / kermit.zip / newsgroups / misc.20000114-20000217 / 000194_news@columbia.edu _Thu Feb 3 18:59:59 2000.msg < prev    next >
Internet Message Format  |  2020-01-01  |  3KB
  1. Return-Path: <news@columbia.edu>
  2. Received: from newsmaster.cc.columbia.edu (newsmaster.cc.columbia.edu [128.59.59.30])
  3.     by watsun.cc.columbia.edu (8.8.5/8.8.5) with ESMTP id SAA27744
  4.     for <kermit.misc@watsun.cc.columbia.edu>; Thu, 3 Feb 2000 18:59:58 -0500 (EST)
  5. Received: (from news@localhost)
  6.     by newsmaster.cc.columbia.edu (8.8.5/8.8.5) id SAA01208
  7.     for kermit.misc@watsun.cc.columbia.edu; Thu, 3 Feb 2000 18:42:03 -0500 (EST)
  8. X-Authentication-Warning: newsmaster.cc.columbia.edu: news set sender to <news> using -f
  9. From: fdc@watsun.cc.columbia.edu (Frank da Cruz)
  10. Subject: Case Study #18: File Timestamps and Permissions
  11. Date: 3 Feb 2000 23:42:02 GMT
  12. Organization: Columbia University
  13. Message-ID: <87d3oa$15l$1@newsmaster.cc.columbia.edu>
  14. To: kermit.misc@columbia.edu
  15.  
  16.  
  17. Ever since the late 1980s, the popular Kermit programs have been able to
  18. send a file's timestamp along with the file, allowing the receiver to give
  19. the incoming file the same timestamp as the original.  This is not just a
  20. frill.  It can also be a useful feature when used in conjunction with SET
  21. FILE COLLISION UPDATE.
  22.  
  23. In case you didn't know about this feature (which is not new at all),
  24. suppose you have MS-DOS Kermit or Kermit 95 on a PC connected to a UNIX or
  25. VMS system that has C-Kermit.  And suppose you have a directory on the PC
  26. containing many files that you work on each day, and you want to back them
  27. up periodically to the UNIX or VMS system (whose file system, in turn, is
  28. backed up to tape for disaster recovery).
  29.  
  30. Obviously you could send all the files every day, but if your connection
  31. is slow and/or the files are large and/or many, this could be tedious and
  32. wasteful.  So just tell the Kermit receiver to:
  33.  
  34.   SET FILE COLLISION UPDATE
  35.  
  36. This means: if a file arrives that has the same name as an existing file,
  37. the receiver is to refuse the incoming file if its timestamp is not newer
  38. the existing file's.  So now if your "send *.*" command matches 200 files,
  39. you don't have to bother about which ones were changed and which were not;
  40. only the ones that were changed are transferred, the rest are skipped
  41. automatically.
  42.  
  43. C-Kermit 7.0 also transmits a new piece of information about each file: its
  44. "protection code" or "permissions".  This is mainly the solve the annoying
  45. problem in which execute permission was lost when transferring from Unix to
  46. Unix.  Now if you use two copies of C-Kermit to transfer a Unix executable
  47. from one Unix system to another, you no longer have to "chmod +x" the result
  48. before you can run it.
  49.  
  50. This new feature works across platforms too; for example, between Unix and
  51. VMS.  If you use C-Kermit 7.0 to send a UNIX executable to VMS and from VMS
  52. back to another Unix system, it keeps its execute permission every step of
  53. the way.
  54.  
  55. Preservation of timestamps and permissions is another feature you won't
  56. find in other cross-platform data transfer protocols like FTP.  When
  57. combined with Kermit's new automatic per-file text/binary-mode switching
  58. and recursive directory traversal capability, you can produce a remarkable
  59. facsimile of a directory tree and all its files from one computer to
  60. another, even if they are different operating systems (but obviously
  61. permissions are lost if one of the OS's -- e.g. DOS or Windows -- does not
  62. have a file system that supports them).
  63.  
  64. Combine all of this with SET FILE COLLISION UPDATE, and you have the classic
  65. incremental backup.
  66.  
  67. - Frank